Using an access increment number to control a duration during which tracks remain in cache

ABSTRACT

Provided are a computer program product, system, and method for using an access increment number to control a duration during which tracks remain in cache. Tracks in a storage in the cache are indicated in a cache list. For each of the tracks indicated in the cache list, an access value is updated when one of the tracks is accessed in the cache. An access to a track in the cache indicated in the cache list is received. A determination is made as to whether an access increment number for the accessed track, wherein the access increment number is greater than one. The access value for the accessed track is incremented by the determined access increment number in response to the track being accessed in the cache. The access value for one of the tracks is used to determine whether to initiate to demote the track from the cache.

BACKGROUND OF THE INVENTION 1. Field of the Invention

The present invention relates to a computer program product, system, andmethod for using an access increment number to control a duration duringwhich tracks remain in cache.

2. Description of the Related Art

A cache management system buffers tracks in a storage device recentlyaccessed as a result of read and write operations in a faster accessstorage device, such as memory, than the storage device storing therequested tracks. Subsequent read requests to tracks in the fasteraccess cache memory are returned at a faster rate than returning therequested tracks from the slower access storage, thus reducing readlatency. The cache management system may also return complete to a writerequest when the modified track directed to the storage device iswritten to the cache memory and before the modified track is written outto the storage device, such as a hard disk drive. The write latency tothe storage device is typically significantly longer than the latency towrite to a cache memory. Thus, using cache also reduces write latency.

A cache management system may maintain a linked list having one entryfor each track stored in the cache, which may comprise write databuffered in cache before writing to the storage device or read data. Inthe commonly used Least Recently Used (LRU) cache technique, if a trackin the cache is accessed, i.e., a cache “hit”, then the entry in the LRUlist for the accessed track is moved to a Most Recently Used (MRU) endof the list. If the requested track is not in the cache, i.e., a cachemiss, then the track in the cache whose entry is at the LRU end of thelist may be removed and demoted and an entry for the track data stagedinto cache from the storage is added to the MRU end of the LRU list.With this LRU cache technique, tracks that are more frequently accessedare likely to remain in cache, while data less frequently accessed willmore likely be removed from the LRU end of the list to make room incache for newly accessed tracks.

When an application accesses a track in the cache, a track identifier ofthe accessed cache needs to be moved to the MRU end of the LRU list. Tomove a track identifier to the MRU end, a lock needs to be obtained onthe LRU list. If multiple processes are trying to access the cache, thencontention for the LRU list lock among the multiple processes may delaycache processing. One technique for reducing lock contention is to limitthe number of times an access track is moved to the MRU end of the LRUlist. To limit the number of times a track is moved to the MRU end whenbeing accessed, an access count indicating a number of times a track hasbeen accessed while in the LRU list is maintained, and the track ismoved to the MRU end when the access count Modulo N is zero. In thisway, the track is moved to the MRU end every N accesses, thus reducingthe lock contention to move the track to the MRU end by a factor of N.

When cache is full, tracks need to be demoted, i.e., removed from cache,to make room for newly accessed tracks. The LRU lists are scanned todetermine unmodified tracks to move to a demote ready LRU list fromwhere the tracks are demoted, i.e., removed, from cache.

There is a need in the art for improved techniques for selecting tracksfor demotion from the cache.

SUMMARY

Provided are a computer program product, system, and method for using anaccess increment number to control a duration during which tracks remainin cache. Tracks in a storage stored in the cache are indicated in acache list. For each of the tracks indicated in the cache list, anaccess value is indicated that is updated when one of the tracks isaccessed in the cache. An access to a track in the cache indicated inthe cache list is received. A determination is made as to whether anaccess increment number for the accessed track, wherein the accessincrement number is greater than one. The access value for the accessedtrack is incremented by the determined access increment number inresponse to the track being accessed in the cache. The access value forone of the tracks is used to determine whether to initiate to demote thetrack from the cache.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an embodiment of a computing environment.

FIG. 2 illustrates an embodiment of a Least Recently Used (LRU) list.

FIG. 3 illustrates an embodiment of a cache control block.

FIG. 4 illustrates an embodiment of cache list information.

FIG. 5 illustrates an embodiment of a track request.

FIGS. 6a and 6b illustrate an embodiment of operations to process arequest for a track.

FIG. 7 illustrates an embodiment of operations to demote a track fromthe cache.

FIG. 8 illustrates an embodiment of a cache expunge request to cause atrack to be demoted from cache.

FIG. 9 illustrates a computing environment in which the components ofFIG. 1 may be implemented

DETAILED DESCRIPTION

To optimize performance, applications may prefer that certain types ofdata remain in cache longer than other types because applicationperformance can be significantly impacted if a cached track is not incache when needed, even though the infrequent access to the trackresults in the track being demoted from the cache. For instance, ametadata track maintains information on numerous customer tracks, suchas 1000, and the application may need the one metadata track to processthe customer tracks. However, given that the presence of a track incache may be very brief, an application may not be able to access themetadata track in cache before it is demoted and the application willexperience cache misses, a cost which can be significant for certaintypes of data, such as metadata.

Described embodiments address the problem of certain important types oftracks being demoted too soon by allowing the application to provide anaccess increment number indicating an amount by which an access value isincremented each access. A track is not demoted unless the access valueis zero and the access value is incremented by the access incrementnumber each time the track is accessed. If the track is not demoted,then it may be moved to the MRU end of an active LRU cache list and theaccess value decremented. Setting an access increment number greaterthan one allows the track to remain in cache by a factor of the accessincrement number because each access increases the access value by theaccess increment number greater than one, whereas moving the track fromthe LRU end to the MRU end only decrements the access value by one.

With the described embodiments, applications can assign access incrementnumbers to different types of data to increase the duration during whichcertain types of data, such as metadata, remain in cache to optimizeoperations, where a higher access increment number maintains the data incache longer than a lower value. Further embodiments provide techniquesfor an application to expunge from cache a track no longer needed toavoid the track unnecessarily consuming cache resources for an extendedtime due to the access increment number.

FIG. 1 illustrates an embodiment of a computing environment. A pluralityof hosts 102 ₁, 102 ₂ . . . 102 _(n) may submit Input/Output (I/O)requests to a storage controller 104 over a network 106 to access dataat volumes 108 (e.g., Logical Unit Numbers, Logical Devices, LogicalSubsystems, etc.) in a storage 110. The storage controller 104 includesone or more processors 112 and a memory 114, including a cache 116 tocache data for the storage 110. The processor 112 may comprise aseparate central processing unit (CPU), one or a group of multiple coreson a single CPU, or a group of processing resources on one or more CPUs.The cache 116 buffers data transferred between the hosts 102 ₁, 102 ₂ .. . 102 _(n) and volumes 108 in the storage 110.

The memory 114 further includes a storage manager 118 for managing thetransfer of tracks transferred between the hosts 102 ₁, 102 ₂ . . . 102_(n) and the storage 110 and a cache manager 120 that manages datatransferred between the hosts 102 ₁, 102 ₂ . . . 102 _(n) and thestorage 110 in the cache 116. A track may comprise any unit of dataconfigured in the storage 110, such as a track, Logical Block Address(LBA), storage cell, group of cells (e.g., column, row or array ofcells), sector, segment, etc., which may be part of a larger grouping oftracks, such as a volume, logical device, etc.

The cache manager 120 maintains cache management information 122 in thememory 114 to manage read (unmodified) and write (modified) tracks inthe cache 116. The cache management information 122 may include a trackindex 124 providing an index of tracks in the cache 116 to cache controlblocks in a control block directory 300, an active Least Recently Used(LRU) cache list 200 _(A) indicating active tracks in the cache 116; anda demote ready list 200 _(DR) indicating a plurality of unmodifiedtracks that are ready to be demoted, i.e., removed, from the cache 116.The control block directory 300 includes the cache control blocks, wherethere is one cache control block for each track in the cache 116providing metadata on the track in the cache 116. The track index 124associates tracks with the cache control blocks providing information onthe tracks in the cache.

In one embodiment, the active LRU cache list 200 _(A) may indicateunmodified and modified data, customer data, and metadata for customerdata maintained in the cache. Each metadata track may provideinformation on numerous customer data tracks in the storage 110.

The cache management information 122 further includes cache listinformation 400 providing information on the active LRU active cachelist 200 _(A), including thresholds and other parameters used to managethe entries in the LRU active cache list 200 _(A).

The cache manager 120 may periodically scan the active LRU cache list200 _(A) to locate unmodified tracks to move to a demote ready list 200_(DR) from which tracks are demoted from the cache 116. When a track isdemoted it is removed from cache 116, or be invalidated so it can beoverwritten.

The storage manager 118 and cache manager 120 are shown in FIG. 1 asprogram code loaded into the memory 114 and executed by one or more ofthe processors 112. Alternatively, some or all of the functions may beimplemented as microcode or firmware in hardware devices in the storagecontroller 104, such as in Application Specific Integrated Circuits(ASICs).

The storage 110 may comprise one or more storage devices known in theart, such as a solid state storage device (SSD) comprised of solid stateelectronics, NAND storage cells, EEPROM (Electrically ErasableProgrammable Read-Only Memory), flash memory, flash disk, Random AccessMemory (RAM) drive, storage-class memory (SCM), Phase Change Memory(PCM), resistive random access memory (RRAM), spin transfer torquememory (STM-RAM), conductive bridging RAM (CBRAM), magnetic hard diskdrive, optical disk, tape, etc. The storage devices may further beconfigured into an array of devices, such as Just a Bunch of Disks(JBOD), Direct Access Storage

Device (DASD), Redundant Array of Independent Disks (RAID) array,virtualization device, etc. Further, the storage devices may compriseheterogeneous storage devices from different vendors or from the samevendor.

The memory 114 may comprise a suitable volatile or non-volatile memorydevices, including those described above.

The network 106 may comprise a Storage Area Network (SAN), a Local AreaNetwork (LAN), a Wide Area Network (WAN), the Internet, and Intranet,etc. Alternatively, the hosts 102 ₁, 102 ₂ . . . 102 _(n) may connect tothe storage controller 104 over a bus interface, such as a PeripheralComponent Interconnect (PCI) bus interface and other interfaces known inthe art.

FIG. 2 illustrates an embodiment of the lists 200 _(A), 200 _(DR), eachas a Least Recently Used (LRU) list, having a most recently used (MRU)end 202 identifying a track most recently added to the cache 116 or mostrecently accessed in the cache 116 and a least recently used (LRU) end204 from which the track identified at the LRU end 204 is selected todemote from the cache 116. The LRU end 204 points to a track identifier,such as a track identifier address or a cache control block index forthe track, of the track that has been in the cache 116 the longest fortracks indicated in that list 200 _(A), 200 _(DR). As a track is addedto the MRU end 202, other tracks move downward toward the LRU end 204.If there is not sufficient space for the track being added to the MRUend 202, then a track may be demoted from the LRU end 204 to make roomfor the new track being added.

FIG. 3 illustrates an embodiment of an instance of a cache control block300 _(i) for one of the tracks in the cache 116, including, but notlimited to, a cache control block identifier 302, such as an index valueof the cache control block 300 _(i); the LRU list 304, e.g., one of LRUlists 200 _(A), 200 _(DR) in which the track associated cache controlblock 300 _(i) is indicated; a track data type 306, such as unmodifiedsequentially accessed track, unmodified non-sequentially accessed track,etc.; a cache timestamp 308 indicating a time the track was added to thecache 116; a demote status 310 indicating whether the track identifiedby the cache control block 300 _(i) is to be demoted from the cache 116and indicated in the demote ready LRU list 200 _(DR), an accessincrement number 312 comprising a number by which to increment theaccess value 314 in response to accessing the track identified by thecache control block 302; and an actual access number 316 indicating anactual number of times the track has been accessed since being added tothe cache 116 and available on the active LRU cache list 200 _(A).

In certain embodiments, the cache timestamp 308 may be set to a sequencenumber that that is periodically incremented, such as at every clockcycle or couple of milliseconds. When the track is added to the cache116, the timestamp 308 is set to the current value for the sequencenumber.

FIG. 4 illustrates an embodiment of cache list information 400,maintained for the active LRU cache list 200 _(A) of parameters used tomanage tracks in the cache 116, including, but not limited to, a cachelist identifier (ID) 402; a demote threshold value 404, such that atrack at the LRU end 204 may be demoted when the access value 314 forthe track exceeds the demote threshold value 404; and an re-MRU number406 indicating a number of times a track is accessed since being at theMRU end 202 of the active LRU cache list 200 _(A) before that track maybe moved to the MRU end 202 of the active LRU cache list 200 _(A).

FIG. 5 illustrates an embodiment of a track request sent by one of thehosts 102 ₁, 102 ₂ . . . 102 _(n) including a request operation (op)code 502 indicating a read or write request; a track identifier (ID) 504identifying the track to access; and an access increment number 506indicating a number by which to increment the access value 314, where ahigher number maintains the track in the cache 116 longer than a lowernumber 506. In this way, the application submitting the track request500 can indicate parameters to control how long a track can remain intrack before being demoted.

FIGS. 6a and 6b illustrate an embodiment of operations performed by thecache manager 120 to process a request 500 for a track. Upon receiving(at block 600) a request 500 for a track, if (at block 602) therequested track 504 is not currently in the cache 116, not indicated inthe active LRU cache list 200 _(A) nor the demote ready LRU list 200_(DR), then the cache manager 120 stages (at block 604) the track fromthe storage 110 into the cache 116 and sets (at block 606) the actualaccess number 316 to one for the track. If (at block 608) the request500 does not include an access increment number 506, then the accessincrement number 312 in the cache control block 300 _(i) of therequested track 504 is set (at block 610) to one or another defaultvalue. If (at block 608) an access increment number 506 is included inthe request 500, then the access increment number 312 in the cachecontrol block 300, is set (at block 612) to the access increment number506 indicated in the request 500. The access value 314 is incremented(at block 614) by the access increment number 312 for the track. Thetrack is indicated (at block 616) at the MRU end 202 of the active LRUcache list 200 _(A) and the requested track is returned (at block 618)to the host 102 ₁, 102 ₂ . . . 102 _(n) that submitted the request 500.

If (at block 602) the requested track 504 is in the cache 116, which maybe determined if the requested track is indicated in the active cacheLRU list 200 _(A) or the demote ready LRU list 200 _(DR), then controlproceeds to block 620 in FIG. 6b where the cache manager 120 determines(at block 620) whether the requested track is indicated in the demoteready LRU list 200 _(DR) or the active LRU cache list 200 _(A). If (atblock 620) the requested track is indicated in the demote ready LRU list200 _(DR), which may be determined by checking the cache list 504 anddemote status 510, then the cache manager 120 moves (at block 622) theindicated track from the demote ready LRU list 200 _(DR) to the MRU end202 of the active LRU cache list 200 _(A).

If (at block 620) the requested cache is on the active LRU cache list200 _(A) from block 620 or 622, then the cache manager 120 determines(at block 624) whether the access increment number 506 in the request500 is greater than the access increment number 312 indicated for thetrack in the cache control block 300 _(i). If so, then the accessincrement number 312 in the cache control block 300, is set (at block626) to the access increment number 506 indicated in the request 500. Inthis way, if a subsequent request 500 to a same track in the cache 116has a higher access increment number, than the access increment number312 is increased to cause the track to remain in cache longer. However,if the subsequent request 500 has a lower access increment number 506,then the access increment number 312 is not lowered so as to not causethe track to be demoted sooner than would occur with a the higherprevious access increment number, which may frustrate the needs of theearlier request 500 requiring a higher access increment number 506.

From block 626, after increasing the access increment number 312 or fromblock 624 if the access increment number 312 is not adjusted, then theaccess value 314 is incremented (at block 628) by the access incrementnumber 312 and the actual access number 316 is incremented (at block630) by one. If (at block 632) the requested track is already at the MRUend 202 of the active LRU cache list 200 _(A), then the requested trackis returned (at block 634) to the requesting host. Otherwise, if (atblock 632) the track is not at the MRU end 202, then the cache manager120 determines (at block 636) whether there have been a pre-selected Nnumber of accesses to the track while in the cache 116 since the trackwas last indicated at the MRU end 202 of the active LRU cache list 200_(A). This determination may be made if the (actual access number 316)modulo N is zero. If (at block 636) the track has been accessed N timessince last at the MRU end 202, then the track is indicated (at block638) at the MRU end 202 of the active LRU cache list 200 _(A). If (atblock 636) the track has not been accessed N times since last at the MRUend 202, then the track is returned (at block 634) and left at itscurrent location in the LRU cache list 200 _(A), without being moved tothe MRU end 202.

FIG. 7 illustrates an embodiment of operations performed by the cachemanager 120 to use the access increment number 312, set according to theoperations of FIGS. 6a , and 6 b, to determine whether to demote a trackonce a track has reached the LRU end 204 of the demote ready list 200_(DR). Upon initiating (at block 700) an operation to demote a track atthe LRU end 204 of the demote ready LRU list 200 _(DR) when the cache116 is full or at a threshold level, the cache manager 120 accesses (atblock 702) the track indicated at the LRU end 204 of the demote readylist 200 _(DR). The cache manager 120 determines (at block 704) whetherthe track at the LRU end 204 of the demote ready LRU list 200 _(DR) hasan access value 314 greater than the demote threshold value 404, e.g.,one. If so, then the track still has a sufficient level of access to notbe demoted and the access value 314 is decremented (at block 704) andthe track is indicated (at block 706) at the MRU end 202 of the activeLRU cache list 200 _(A). Control then returns to block 702 to attempt toselect another track at the LRU end 204 to demote.

If (at block 704) the track at the LRU end 204 has an access value 314equal to zero, then the track has reached the LRU end 204 a sufficientnumber of times to have its access value 314 decremented to zero withoutbeing accessed, which would increase its access value 314 by the accessincrement number 312 to offset the decrementing operation at block 706.In such case, the track is indicated (at block 708) at the MRU end 202of the active LRU cache list 200 _(A) and removed from the demote readyLRU list 200 _(DR).

With the operations of FIGS. 6a, 6b , and 7, different applications mayprovide different access increment numbers 506 for use with tracks incache 116 to alter how long tracks remain in cache 116. Further, certainapplications may use different access increment numbers 506 fordifferent types of data to cause certain types of data to remain incache 116 longer or shorter than other types of data. For instance, anapplication requiring metadata to optimize operations may submit anaccess increment number 506 for metadata that is greater than the accessincrement number provided for customer data so that metadata stays incache 116 longer than customer data. Similar distinctions may be madefor other types of data required by the application to optimizeperformance. The described embodiments cause a track to remain in cache116 longer by incrementing the access value 314 by a greater amount,i.e., the access increment number 312, then the amount the access value314 is decremented when reaching the LRU end 204. Thus, each of Taccesses resulting in the access value 314 increasing by M, the accessincrement number 312, will cause the track to at least be moved from theLRU end 204 of the demote ready list 200 _(DR) to the MRU end 202 of theactive LRU cache list 200 _(A) T*M times before being demoted. In thisway, increasing the access increment number 312 increases the number oftimes a track avoids demotion and is added back to the MRU end 202 ofthe active LRU cache list 200 _(A) by a factor of M.

FIG. 8 illustrates an embodiment of a cache expunge request 800 that thehosts 102 ₁, 102 ₂ . . . 102 _(n) may submit to cause the cache manager120 to remove a track from cache. The request 800 includes a cacheexpunge request code 802 and a track identifier (ID) 804 of the track toexpunge. This request 800 causes the cache manager 120 to immediatelymove indication of the track 804 to the MRU end 202 of the demote readylist 200 _(DR) if the track 804 is on the active LRU cache list 200_(A). If the track is already on the demote ready LRU list 200 _(DR),then it would just remain there for demotion. With this expunge request800, an application that assigned a high access increment number 312 toprevent a track from being demoted may then cause that track to bedemoted by adding the track to the demote ready LRU list 200 _(DR) sothat it does not remain in the cache 116 for a long time based on theaccess increment number 312 and unnecessarily consume cache resources.

Described embodiments provide techniques to cause a track to remain incache longer by providing an access increment number greater than one tocause the track not to be demoted when the track reaches the LRU end ofthe demote ready LRU list until after reaching the LRU end of the demoteready LRU list a multiple number of times without receiving an access tothe track. Described embodiments allow applications to specify differentaccess increment numbers for different types of data to cause differenttypes of tracks to remain in cache for different periods of time bydelaying the demotion of the track using the access increment value.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,in order to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a particular manner, such that the computerreadable storage medium having instructions stored therein comprises anarticle of manufacture including instructions which implement aspects ofthe function/act specified in the flowchart and/or block diagram blockor blocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

The computational components of FIG. 1, including the hosts 102 ₁, 102 ₂. . . 102 _(n) and storage controller 104, may be implemented in one ormore computer systems, such as the computer system 902 shown in FIG. 9.Computer system/server 902 may be described in the general context ofcomputer system executable instructions, such as program modules, beingexecuted by a computer system. Generally, program modules may includeroutines, programs, objects, components, logic, data structures, and soon that perform particular tasks or implement particular abstract datatypes. Computer system/server 902 may be practiced in distributed cloudcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed cloud computing environment, program modules may be locatedin both local and remote computer system storage media including memorystorage devices.

As shown in FIG. 9, the computer system/server 902 is shown in the formof a general-purpose computing device. The components of computersystem/server 902 may include, but are not limited to, one or moreprocessors or processing units 904, a system memory 906, and a bus 908that couples various system components including system memory 906 toprocessor 904. Bus 908 represents one or more of any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, an accelerated graphics port, and a processor or localbus using any of a variety of bus architectures. By way of example, andnot limitation, such architectures include Industry StandardArchitecture (ISA) bus, Micro Channel Architecture (MCA) bus, EnhancedISA (EISA) bus, Video Electronics Standards Association (VESA) localbus, and Peripheral Component Interconnects (PCI) bus.

Computer system/server 902 typically includes a variety of computersystem readable media. Such media may be any available media that isaccessible by computer system/server 902, and it includes both volatileand non-volatile media, removable and non-removable media.

System memory 906 can include computer system readable media in the formof volatile memory, such as random access memory (RAM) 910 and/or cachememory 912. Computer system/server 902 may further include otherremovable/non-removable, volatile/non-volatile computer system storagemedia. By way of example only, storage system 913 can be provided forreading from and writing to a non-removable, non-volatile magnetic media(not shown and typically called a “hard drive”). Although not shown, amagnetic disk drive for reading from and writing to a removable,non-volatile magnetic disk (e.g., a “floppy disk”), and an optical diskdrive for reading from or writing to a removable, non-volatile opticaldisk such as a CD-ROM, DVD-ROM or other optical media can be provided.In such instances, each can be connected to bus 908 by one or more datamedia interfaces. As will be further depicted and described below,memory 906 may include at least one program product having a set (e.g.,at least one) of program modules that are configured to carry out thefunctions of embodiments of the invention.

Program/utility 914, having a set (at least one) of program modules 916,may be stored in memory 906 by way of example, and not limitation, aswell as an operating system, one or more application programs, otherprogram modules, and program data. Each of the operating system, one ormore application programs, other program modules, and program data orsome combination thereof, may include an implementation of a networkingenvironment. The components of the computer 902 may be implemented asprogram modules 916 which generally carry out the functions and/ormethodologies of embodiments of the invention as described herein. Thesystems of FIG. 1 may be implemented in one or more computer systems902, where if they are implemented in multiple computer systems 902,then the computer systems may communicate over a network.

Computer system/server 902 may also communicate with one or moreexternal devices 918 such as a keyboard, a pointing device, a display920, etc.; one or more devices that enable a user to interact withcomputer system/server 902; and/or any devices (e.g., network card,modem, etc.) that enable computer system/server 902 to communicate withone or more other computing devices. Such communication can occur viaInput/Output (I/O) interfaces 922. Still yet, computer system/server 902can communicate with one or more networks such as a local area network(LAN), a general wide area network (WAN), and/or a public network (e.g.,the Internet) via network adapter 924. As depicted, network adapter 924communicates with the other components of computer system/server 902 viabus 908. It should be understood that although not shown, other hardwareand/or software components could be used in conjunction with computersystem/server 902. Examples, include, but are not limited to: microcode,device drivers, redundant processing units, external disk drive arrays,RAID systems, tape drives, and data archival storage systems, etc.

The terms “an embodiment”, “embodiment”, “embodiments”, “theembodiment”, “the embodiments”, “one or more embodiments”, “someembodiments”, and “one embodiment” mean “one or more (but not all)embodiments of the present invention(s)” unless expressly specifiedotherwise.

The terms “including”, “comprising”, “having” and variations thereofmean “including but not limited to”, unless expressly specifiedotherwise.

The enumerated listing of items does not imply that any or all of theitems are mutually exclusive, unless expressly specified otherwise.

The terms “a”, “an” and “the” mean “one or more”, unless expresslyspecified otherwise.

Devices that are in communication with each other need not be incontinuous communication with each other, unless expressly specifiedotherwise. In addition, devices that are in communication with eachother may communicate directly or indirectly through one or moreintermediaries.

A description of an embodiment with several components in communicationwith each other does not imply that all such components are required. Onthe contrary a variety of optional components are described toillustrate the wide variety of possible embodiments of the presentinvention.

When a single device or article is described herein, it will be readilyapparent that more than one device/article (whether or not theycooperate) may be used in place of a single device/article. Similarly,where more than one device or article is described herein (whether ornot they cooperate), it will be readily apparent that a singledevice/article may be used in place of the more than one device orarticle or a different number of devices/articles may be used instead ofthe shown number of devices or programs. The functionality and/or thefeatures of a device may be alternatively embodied by one or more otherdevices which are not explicitly described as having suchfunctionality/features. Thus, other embodiments of the present inventionneed not include the device itself.

The foregoing description of various embodiments of the invention hasbeen presented for the purposes of illustration and description. It isnot intended to be exhaustive or to limit the invention to the preciseform disclosed. Many modifications and variations are possible in lightof the above teaching. It is intended that the scope of the invention belimited not by this detailed description, but rather by the claimsappended hereto. The above specification, examples and data provide acomplete description of the manufacture and use of the composition ofthe invention. Since many embodiments of the invention can be madewithout departing from the spirit and scope of the invention, theinvention resides in the claims herein after appended.

What is claimed is:
 1. A computer program product for managing tracks ina storage in a cache, the computer program product comprising a computerreadable storage medium having computer readable program code embodiedtherein that when executed performs operations, the operationscomprising: receiving an application access increment number provided byan application for a track in the cache, wherein the application accessincrement number comprises one of a plurality of values used to controla duration during which the track is maintained in the cache; inresponse to a request for the track in the cache, incrementing an accessvalue for the track by the application access increment number; andusing the access value for the track in the cache to determine whetherto demote the track from the cache.
 2. The computer program product ofclaim 1, wherein the operations further comprise: receiving a requestfor the track from the application, wherein the request includes theapplication access increment number.
 3. The computer program product ofclaim 2, wherein the operations further comprise: incrementing theaccess value for the track by a default value in response to the requestfor the track not including the application access increment number. 4.The computer program product of claim 1, wherein the plurality of valuesfor the application access increment number are used for different typesof data, wherein a higher access increment number is used for a firsttype of data to cause the first type of data to remain in the cachelonger than a second type of data for which a lower access incrementnumber is used, wherein the lower access increment number is less thanthe higher access increment number.
 5. The computer program product ofclaim 4, wherein the first type of data comprises metadata and whereinthe second type of data comprises consumer data, wherein the metadataprovides metadata for multiple tracks of consumer data.
 6. The computerprogram product of claim 1, wherein the operations further comprise:moving unmodified tracks in the cache indicated in a cache list,indicating tracks in the storage stored in the cache, to a demote readylist of tracks; using the access value for a track in the demote readylist considered for demotion to determine whether to maintain the trackconsidered for demotion in the cache; and in response to determiningthat the access value indicates to move the track considered fordemotion to the cache list, removing indication of the track consideredfor demotion from the demote ready list and adding indication of thetrack considered for demotion to the cache list.
 7. The computer programproduct of claim 1, wherein the operations further comprise: determiningwhether there have been N number of accesses to a track in the cachesince the track was last indicated at a most recently used (MRU) end ofa cache list indicating tracks in the storage stored in the cache,wherein a track in cache that is accessed is indicated at the MRU end ofthe cache list; and indicating the track at the MRU end of the cachelist in response to determining that there have been N number ofaccesses to the track since the track was last indicated at the MRU endof the cache list.
 8. A system for managing tracks in a storage in acache, comprising: a processor; a memory including a cache; a computerreadable storage medium having computer readable program code embodiedtherein that when executed performs operations, the operationscomprising: receiving an application access increment number provided byan application for a track in the cache, wherein the application accessincrement number comprises one of a plurality of values used to controla duration during which the track is maintained in the cache; inresponse to a request for the track in the cache, incrementing an accessvalue for the track by the application access increment number; andusing the access value for the track in the cache to determine whetherto demote the track from the cache.
 9. The system of claim 8, whereinthe operations further comprise: receiving a request for the track fromthe application, wherein the request includes the application accessincrement number.
 10. The system of claim 9, wherein the operationsfurther comprise: incrementing the access value for the track by adefault value in response to the request for the track not including theapplication access increment number.
 11. The system of claim 8, whereinthe plurality of values for the application access increment number areused for different types of data, wherein a higher access incrementnumber is used for a first type of data to cause the first type of datato remain in the cache longer than a second type of data for which alower access increment number is used, wherein the lower accessincrement number is less than the higher access increment number. 12.The system of claim 11, wherein the first type of data comprisesmetadata and wherein the second type of data comprises consumer data,wherein the metadata provides metadata for multiple tracks of consumerdata.
 13. The system of claim 8, wherein the operations furthercomprise: moving unmodified tracks in the cache indicated in a cachelist, indicating tracks in the storage stored in the cache, to a demoteready list of tracks; using the access value for a track in the demoteready list considered for demotion to determine whether to maintain thetrack considered for demotion in the cache; and in response todetermining that the access value indicates to move the track consideredfor demotion to the cache list, removing indication of the trackconsidered for demotion from the demote ready list and adding indicationof the track considered for demotion to the cache list.
 14. The systemof claim 8, wherein the operations further comprise: determining whetherthere have been N number of accesses to a track in the cache since thetrack was last indicated at a most recently used (MRU) end of a cachelist indicating tracks in the storage stored in the cache, wherein atrack in cache that is accessed is indicated at the MRU end of the cachelist; and indicating the track at the MRU end of the cache list inresponse to determining that there have been N number of accesses to thetrack since the track was last indicated at the MRU end of the cachelist.
 15. A method for managing tracks in a storage in a cache,comprising: receiving an application access increment number provided byan application for a track in the cache, wherein the application accessincrement number comprises one of a plurality of values used to controla duration during which the track is maintained in the cache; inresponse to a request for the track in the cache, incrementing an accessvalue for the track by the application access increment number; andusing the access value for the track in the cache to determine whetherto demote the track from the cache.
 16. The method of claim 15, furthercomprising: receiving a request for the track from the application,wherein the request includes the application access increment number.17. The method of claim 16, further comprising: incrementing the accessvalue for the track by a default value in response to the request forthe track not including the application access increment number.
 18. Themethod of claim 15, wherein the plurality of values for the applicationaccess increment number are used for different types of data, wherein ahigher access increment number is used for a first type of data to causethe first type of data to remain in the cache longer than a second typeof data for which a lower access increment number is used, wherein thelower access increment number is less than the higher access incrementnumber.
 19. The method of claim 18, wherein the first type of datacomprises metadata and wherein the second type of data comprisesconsumer data, wherein the metadata provides metadata for multipletracks of consumer data.
 20. The method of claim 15, further comprising:moving unmodified tracks from in the cache indicated in a cache list,indicating tracks in the storage stored in the cache, to a demote readylist of tracks; using the access value for a track in the demote readylist considered for demotion to determine whether to maintain the trackconsidered for demotion in the cache; and in response to determiningthat the access value indicates to move the track considered fordemotion to the cache list, removing indication of the track consideredfor demotion from the demote ready list and adding indication of thetrack considered for demotion to the cache list.
 21. The method of claim15, further comprising: determining whether there have been N number ofaccesses to a track in the cache since the track was last indicated at amost recently used (MRU) end of a cache list indicating tracks in thestorage stored in the cache, wherein a track in cache that is accessedis indicated at the MRU end of the cache list; and indicating the trackat the MRU end of the cache list in response to determining that therehave been N number of accesses to the track since the track was lastindicated at the MRU end of the cache list.